做一个不崩溃的核酸系统有多难？
然后，系统启动过程是：
1、从数据库载入属于本服务器的所有信息（2~4亿条），这是个较为缓慢的过程。
2、开始提供服务。
前面提到过，哪怕按2000万次访问集中在1小时内完成这个最苛刻的指标，每秒也只需服务5556人。
按每人需要返回2K数据计算（1k都绰绰有余！除非你在服务器端生成二维码），每秒数据量大约是12M不到。
这个业务都是短链接。也就是可以认为用户查询过程是：TCP握手，发送用户身份证号（可本地识别），获取数据，断开连接。
那么，这里实际上不太需要考虑什么C10k问题（考虑也容易，Windows用完成端口Linux用epoll即可；其实可以直接用libevent写出跨平台程序的），一条100M的链路足够了。
按身份证号在数组中搜索信息，在搞好身份证号-下标映射算法时，效率是O(1)；没有搞好、用二分法查找，效率O(lnN)，对10亿人，至多30次搜索就能找到。对于内存搜索，相对于网络的蜗牛速率，这个延迟可以忽略不计。
换句话说，不需要任何特殊技术，20台16G内存的虚拟机实例，简单的在数组中访问下标（或者二分查找）、封装返回，以及100M对外服务总带宽，就足以支持10亿用户的每小时2000万次查询——性能大有盈余。
换成1G总带宽，一小时够2亿人用的——注意我说的是总带宽。如果20台16G内存的虚拟机实例各自拥有100M对外服务带宽，它实际上已经足够支持全国使用了。
当然，实际不能这么简陋。万一虚拟机本身不够稳定、或者有人连二分查找程序都能写崩溃呢……
这时候，我们可以另外搞一些虚拟机作为备份；这些虚拟机可以使用现成的zookeeper管理，一个节点坏了，另一个节点可以马上顶上……
这可以在数据库服务器上放置一个触发器；数据有变动就自动通知外围节点，让这些节点更新数据即可。总之，全都是最最简单的基础逻辑，找“会快排的程序员”都有点大材小用了。
但是呢，我曾经在类似的公司做过事，也知道对接的甲方的水平……
所以，这样一个“庞大”“复杂”“史无前例”的系统，最终如果按我的设计，顶天两三千行C代码以及两三千行js代码就交差了——你猜甲方会不会掏钱？
不不不，这都不是甲方懂不懂的问题了；而是，就这么几行代码，你想让他们掏多少？他们怎么向上面交代？
妙在这东西太简单，你就找一群棒槌，他们瞎凑合出来也能交差，至多多买点服务器、多出点事故——但只有这样，才更能证明钱花得值，不是吗？
原文链接：https://urlify.cn/zuiYrq 作者：invalid s